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1. Introduction 


The Generalized Multi-Protocol Label Switching (GMPLS) suite of 
protocols allows for the automated control of different switching 
technologies, including the Synchronous Optical Network (SONET), 
Synchronous Digital Hierarchy (SDH), Optical Transport Network (OTN), 
and Plesiochronous Digital Hierarchy (PDH). This document updates 
the procedures described in [RFC4606] to allow supporting additional 
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applications of the Virtual Concatenation (VCAT) layer 1 inverse 
multiplexing mechanism that has been standardized for SONET, SDH, 
OTN, and PDH [ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043] 
technologies, along with its companion Link Capacity Adjustment 
Scheme (LCAS) [ITU-T-G.7042]. 


VCAT is a time-division multiplexing (TDM)-oriented byte striping 
inverse multiplexing method that works with a wide range of existing 
and emerging TDM framed signals, including very-high-bit-rate OTN and 
SDH/SONET signals. VCAT enables the selection of an optimal signal 
server bandwidth (size) utilizing a group of server signals and 
provides for efficient use of bandwidth in a mesh network. When 
combined with LCAS, hitless dynamic resizing of bandwidth and fast 
graceful degradation in the presence of network faults can be 
supported. To take full advantage of VCAT/LCAS functionality, 
additional extensions to GMPLS signaling are needed that enable the 
setup of diversely routed signals that are members of the same VCAT 
group. Note that the scope of this document is limited to scenarios 
where all member signals of a VCAT group are controlled using 
mechanisms defined in this document and related RFCs. Scenarios 
where a subset of member signals are controlled by a management plane 
or a proprietary control plane are outside the scope of this 
document. 


1.1. Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. VCAT/LCAS Scenarios and Specific Requirements 


There are a number of specific requirements for the support of 
VCAT/LCAS in GMPLS that can be derived from the carriers’ 
applications for the use of VCAT/LCAS. These are set out in the 
following section. 


2.1. VCAT/LCAS Interface Capabilities 


In general, a label switched router (LSR) can be an ingress/egress of 
one or more VCAT groups.  VCAT and LCAS are data plane interface 
capabilities. An LSR may have, for example, VCAT-capable interfaces 
that are not LCAS-capable. It may at the same time have interfaces 
that are neither VCAT-capable nor LCAS-capable. 
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2.2. Member Signal Configuration Scenarios 


We list in this section the different scenarios. Here we use the 
[ITU-T-G.707] term "VCG" to refer to the VCAT group and the 
terminology "set" and "subset" to refer to the subdivision of the 
group and the individual VCAT group member signals. As noted above, 
the scope of these scenarios is limited to scenarios where all member 
signals are controlled using mechanisms defined in this document. 


The scenarios listed here are dependent on the terms "co-routed" and 
"diversely routed". In the context of this document, "co-routed" 
refers to a set of VCAT signals that all traverse the same sequence 
of switching nodes. Furthermore, a co-routed set of signals between 
any pair of adjacent nodes utilizes a set of links that have similar 
delay characteristics. Thus, "diversely routed" means a set of 
signals that are not classed as "co-routed". 


Fixed, co-routed: A fixed-bandwidth VCG, transported over a co-routed 
set of member signals. This is the case where the intended 
bandwidth of the VCG does not change and all member signals follow 
the same route to minimize differential delay. The application 
here is the capability to allocate an amount of bandwidth close to 
that required at the client layer. 


Fixed, diversely routed: A fixed-bandwidth VCG, transported over at 
least two diversely routed subsets of member signals. In this 
case, the subsets are link-disjoint over at least one link of the 
route. The application here is more efficient use of network 
resources, e.g., no unique route has the required bandwidth. 


Fixed, member sharing: A fixed-bandwidth VCG, transported over a set 
of member signals that are allocated from a common pool of 
available member signals without requiring member connection 
teardown and setup. This document only covers the case where this 
pool of "potential" member signals has been established via 
mechanisms defined in this document. Member signals need not be 
co-routed or be guaranteed to be diversely routed. Note that by 
the nature of VCAT, a member signal can only belong to one VCG at 
a time. To be used in a different VCG, a signal must first be 
removed from any VCG to which it may belong. 


Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or 
decreased via the addition or removal of member signals), 
transported over a co-routed set of members. The application here 
is dynamic resizing and resilience of bandwidth. 
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Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased 
or decreased via the addition or removal of member signals), 
transported over at least two diversely routed subsets of member 
Signals. The application here is efficient use of network 
resources, dynamic resizing, and resilience of bandwidth. 


Dynamic, member sharing: A dynamic-bandwidth VCG, transported over a 
set of member signals that are allocated from a common pool of 
available member signals without requiring member connection 
teardown and setup. 


2.3. VCAT Operation with or without LCAS 


VCAT capabilities may be present with or without the presence of 
LCAS. The use of LCAS is beneficial in the provisioning of flexible 
bandwidth services, but in the absence of LCAS, VCAT is still a valid 
technique. Therefore, GMPLS mechanisms for the operation of VCAT are 
REQUIRED for both the case where LCAS is available and the case where 
it is not available. The GMPLS procedures for the two cases SHOULD 
be identical. 


o GMPLS signaling for LCAS-capable interfaces MUST support all 
Scenarios described in Section 2.2 with no loss of traffic. 


o GMPLS signaling for non-LCAS-capable interfaces MUST support the 
"fixed" scenarios described in Section 2.2. 


To provide for these requirements, GMPLS signaling MUST carry the 
following information on behalf of the VCAT endpoints: 


o The type of the member signal that the VCG will contain, e.g., 
VC-3, VC-4, etc. 


o The total number of members to be in the VCG. This provides the 
endpoints in both the LCAS and non-LCAS case with information on 
which to accept or reject the request, and in the non-LCAS case 
will let the receiving endpoint know when all members of the VCG 
have been established. 


o Identification of the VCG and its associated members. This 
provides information that allows the endpoints to differentiate 
multiple VCGs and to tell what member, label switched paths 
(LSPs), to associate with a particular VCG. 
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2.4.  VCGs and VCG Members 


The signaling solution SHOULD provide a mechanism to support these 
scenarios: 


o VCG members (server-layer connections) may be set up prior to 
their use in a VCG. 


o VCG members (server-layer connections) may exist after their 
corresponding VCG has been removed. 


However, it is not required that any arbitrarily created server-layer 
connection be supported in the above scenarios, i.e., connections 
established without following the procedures described in this 
document. 


3. VCAT Data and Control Plane Concepts 


When utilizing GMPLS with VCAT/LCAS, we use a number of control and 
data plane concepts described below. 


VCG - This is the group of data plane server-layer signals used to 
provide the bandwidth for the virtual concatenation link 
connection through a network ([ITU-T-G.7042]). 


VCG member - This is an individual data plane server-layer signal 
that belongs to a VCG ([ITU-T-G.7042]). 


Member set - One or more VCG members (or potential members) set up 
via the same control plane signaling exchange. Note that all 
members in a member set follow the same route. 

Data plane LSP - This is an individual VCG member. 

Control plane LSP - A control plane entity that can control multiple 
data plane LSPs. For our purposes here, this is equivalent to the 


member set. 


Call - A control plane mechanism for providing association between 
endpoints and possibly key transit points. 
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4.  VCGs Composed of a Single Member Set (One LSP) 


In this section and the next section, we will describe the procedures 
for supporting the applications described in Section 2. 


This section describes the support of a single VCG composed of a 
Single member set (in support of the fixed, co-routed application and 
the dynamic, co-routed application) using existing GMPLS procedures 


[RFC4606]. Note that this section is included for informational 
purposes only and does not modify [RFC4606]. It is provided to show 
how the existing GMPLS procedures may be used. [RFC4606] provides 


the normative definition for GMPLS processing of VCGs composed of a 
single member set, and in the event of any conflict between this 
section and that document, [RFC4606] takes precedence. 


The existing GMPLS signaling protocols support a VCG composed of a 
single member set. Setup using the Number of Virtual Components 
(NVC) field is explained in Section 2.1 of [RFC4606]. In this case, 
one (single) control plane LSP is used in support of the VCG. 


There are two options for setting up the VCG, depending on policy 
preferences: one-shot setup and incremental setup. 


The following sections explain the procedure based on an example of 
setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v 
SONET VCAT group), which is composed of 7 virtually concatenated 
VC-4s (or STS-3c). 


4.1. One-Shot VCG Setup 
This section describes establishment of an LSP that supports all VCG 
members as part of the initial LSP establishment. To establish such 
an LSP, an RSVP-TE (Resource Reservation Protocol - Traffic 
Engineering) Path message is sent containing the SONET/SDH traffic 
parameters defined in [RFC4606]. In the case of this example: 
o Elementary signal is set to 6 (for VC-4/STS-3c SPE). 
o NVC is set to 7 (number of members). 
o Per [RFC4606], a Multiplier Transform greater than 1 (say N > 1) 


may be used if the operator wants to set up N identical VCAT 
groups (for the same LSP). 
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o SDH or SONET labels have to be assigned for each member of the VCG 
and concatenated to form a single Generalized Label constructed as 
an ordered list of 32-bit timeslot identifiers of the same format 
as TDM labels. [RFC4606] requires that the order of the labels 
reflect the order of the payloads to concatenate, and not the 
physical order of timeslots. 


o Refer to [RFC4606] for other traffic parameter settings. 
4.2. Incremental VCG Setup 


In some cases, it may be necessary or desirable to set up the VCG 
members individually, or to add group members to an existing group. 


One example of this need is when the local policy requires that VCAT 
can only add VCAT members one at a time or cannot automatically match 
the members at the ingress and egress for the purposes of inverse 
multiplexing. Serial or incremental setup solves this problem. 


In order to accomplish incremental setup, an iterative process is 
used to add group members. For each iteration, NVC is incremented up 
to the final value required. A successful iteration consists of the 
successful completion of Path and Resv signaling. At first, NVC = 1, 
and the label includes just one timeslot identifier. 


At each of the next iterations, NVC is set to (NVC + 1), and one more 
timeslot identifier is added to the ordered list in the Generalized 
Label (in the Path or Resv message). A node that receives a Path 
message that contains changed fields will process the full Path 
message and, based on the new value of NVC, it will add a component 
signal to the VCAT group, and switch the new timeslot based on the 
new label information. 


Following the addition of the new label (identifying the new member) 
to the LSP, in the data plane, LCAS may be used to add the new member 
at the endpoints into the existing VCAT group. LCAS (data plane) 
signaling is described in [ITU-T-G.7042]. 


4.3. Procedure for VCG Reduction by Removing a Member 


The procedure to remove a component signal is similar to that used to 
add components as described in Section 4.2. In the data plane, LCAS 

signaling is used first to take the component out of service from the 
group. LCAS signaling is described in [ITU-T-G.7042]. 


In this case, the NVC value is decremented by 1, and the timeslot 
identifier for the dropped component is removed from the ordered list 
in the Generalized Label. 
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Note that for interfaces that are not LCAS-capable, removing one 
component of the VCG will result in failure detection of the member 
at the endpoint and failure of the whole group. So, this is a 
feature that only LCAS-capable VCAT interfaces can support without 
management intervention at the endpoints. 


Note that if using LCAS, a VCG member can be temporarily removed from 
the VCG due to a failure of the component signal. The LCAS data 
plane signaling will take appropriate actions to adjust the VCG as 
described in [ITU-T-G.7042]. 


4.4. Removing Multiple VCG Members in One Shot 


The procedure is similar to that described in Section 4.3. In this 
case, the NVC value is changed to the new value, and all relevant 
timeslot identifiers for the components to be torn down are removed 
from the ordered list in the Generalized Label. This procedure is 
also not supported for VCAT-only interfaces without management 
intervention, as removing one or more components of the VCG will tear 
down the whole group. 


4.5.  Teardown of Whole VCG 
The entire LSP is deleted in a single step (i.e., all components are 
removed in one go) using the deletion procedures described in 
[RFC3473]. 

5. VCGs Composed of Multiple Member Sets (Multiple LSPs) 


The motivation for VCGs composed of multiple member sets comes from 


the requirement to support VCGs with diversely routed members. The 
initial GMPLS specification did not support diversely routed signals 
using the NVC construct. [RFC4606] says: 


[...] The standard definition for virtual concatenation allows 
each virtual concatenation component to travel over diverse paths. 
Within GMPLS, virtual concatenation components must travel over 
the same (component) link if they are part of the same LSP. This 
is due to the way that labels are bound to a (component) link. 
Note, however, that the routing of components on different paths 
is indeed equivalent to establishing different LSPs, each one 
having its own route. Several LSPs can be initiated and 
terminated between the same nodes, and their corresponding 
components can then be associated together (i.e., virtually 
concatenated). 


The setup of diversely routed VCG members requires multiple VCG 
member sets, i.e., multiple control plane LSPs. 
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The support of a VCG with multiple VCG member sets requires being 
able to identify separate sets of control plane LSPs with a single 
VCG and exchange information pertaining to the VCG as a whole between 
the endpoints. This document updates the procedures described in 
[RFC4606] to provide this capability by using the call procedures and 
extensions described in [RFC4974]. The VCG makes use of one or more 
calls (VCAT calls) to associate control plane LSPs in support of VCG 
server-layer connections (VCG members) in the data plane. Note that 
the trigger for the VCG (by management plane or client layer) is 


outside the scope of this document. These procedures provide for 
autonomy of the client layer and server layer with respect to their 
management. 


In addition, by supporting the identification of a VCG (VCG ID) and 
VCAT call identification (VCAT Call ID), support can be provided for 
the member-sharing scenarios, i.e., by explicitly separating the VCG 
ID from the VCAT call ID. Note that per [RFC4974], LSPs 
(connections) cannot be moved from one call to another; hence, to 
support member sharing, the procedures in this document provide 
support by moving call(s) and their associated LSPs from one VCG to 
another. Figure 1 below illustrates these relationships; however, 
note that VCAT calls can exist independently of a VCG (for connection 
pre-establishment), as will be described later in this document. 


4R------- + 4+------------- + 4+------- + +------------ + 
| |1 n| |1 n| |1 n| Data Plane | 
| vce |<>----| vCAT Call |<>----| LSP |<>----| Connection | 

| | | (co-routed) | 
+------- + 4+------------- + +------- + +------------ + 


Figure 1. Conceptual Containment Relationship between VCG, VCAT 
Calls, Control Plane LSPs, and Data Plane Connections 


5.1. Signaled VCG Service Layer Information 


In this section, we provide information that will be communicated at 
the VCG level, i.e., between the VCG signaling endpoints using the 
call procedures described in [RFC4974]. To accommodate the VCG 
information, a new TLV is defined in this document for the 
CALL_ATTRIBUTES object [RFC6001] for use in the Notify message 
[RFC4974]. The Notify message is a targeted message and does not 
need to follow the path of LSPs through the network; i.e., there is 
no dependency on the member signaling for establishing the VCAT call, 
and the use of external call managers as described in [RFC4974] is 
not precluded. 
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The following information is needed: 

1. Signal type 

2. Number of VCG members 

3. LCAS requirements: 
a. LCAS required 
b. LCAS desired 
c. LCAS not supported 

4. VCG Identifier - Used to identify a particular VCG separately from 
the call ID so that call members can be reused with different VCGs 
per the requirements for member sharing and the requirements of 
Section 2.4. 


5.2. CALL ATTRIBUTES Object VCAT TLV 


This document defines a CALL ATTRIBUTES object VCAT TLV for use in 
the CALL ATTRIBUTES object [RFC6001] as follows: 


0 1 2 3 
01.23 456078 9012 34560789012 35459679899 01 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Type = 4 | Length = 12 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Signal Type | Number of Members 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|LCR| Reserved | Action | VCG ID 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Type, as defined in [RFC6001]. This field MUST be set to 2. 
Length, as defined in [RFC6001]. This field MUST be set to 12. 


Signal Type: 16 bits 


The signal types can never be mixed in a VCG; hence, a VCAT call 
contains only one signal type. This field can take the following 
values and MUST never change over the lifetime of a VCG 
[ANSI-T1.105] [ITU-T-G.707] [ITU-T-G.709] [ITU-T-G.7043]: 
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Value Type (Elementary Signal) 


1 VT1.5 SPE / VC-11 

2 VT2 SPE / VC-12 

3 STS-1 SPE / VC-3 

4 STS-3c SPE / VC-4 

11 ODU1 (i.e., 2.5 Gbit/s) 
12 ODU2 (i.e., 10 Gbit/s) 
1-3 ODU3 (i.e., 40 Gbit/s) 
21 Tl (i.e., 1.544 Mbps) 
22 El (i.e., 2.048 Mbps) 
23 E3 (i.e., 34.368 Mbps) 
24 I3 (i.e., 44.736 Mbps) 


Number of Members: 16 bits 


This field is an unsigned integer that MUST indicate the total 
number of members in the VCG (not just the call). This field MUST 
be changed (over the life of the VCG) to indicate the current 
number of members. 


LCR (LCAS Required): 2 bits 


This field can take the following values and MUST NOT change over 
the life of a VCG: 


Value Meaning 
0 LCAS required 
1 LCAS desired 
2 LCAS not supported 


Action: 8 bits 


This field is used to indicate the relationship between the call 
and the VCG and has the following values: 


Value Meaning 
0 No VCG ID (set up call prior to VCG creation) 
1 New VCG for Call 
2 Modification of Number of Members (no change in VCG ID) 
3 Remove VCG from Call 
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VCG Identifier (ID): 16 bits 


This field carries an unsigned integer that is used to identify a 

particular VCG within a session. The value of the field MUST NOT 

change over the lifetime of a VCG but MAY change over the lifetime 
of a call. 


5.3. Procedures for Multiple Member Sets 


The creation of a VCG based on multiple member sets requires the 
establishment of at least one VCAT-layer call.  VCAT-layer calls and 
related LSPs (connections) MUST follow the procedures as defined in 
[RFC4974], with the addition of the inclusion of a CALL ATTRIBUTES 
object containing the VCAT TLV. Multiple VCAT layer calls per VCG 
are not required to support member sets, but are needed to support 
certain member-sharing scenarios. 


The remainder of this section provides specific procedures related to 
VCG signaling. The procedures described in [RFC4974] are only 
modified as discussed in this section. 


When LCAS is supported, the data plane will add or decrease the 
members per [ITU-T-G.7042]. When LCAS is not supported across LSPs, 
the data plane coordination across member sets is outside the scope 
of this document. 


5.3.1. Setting Up a New VCAT Call and VCG Simultaneously 


To simultaneously set up a VCAT call and identify it with an 
associated VCG, a CALL ATTRIBUTES object containing the VCAT TLV MUST 
be included in the Notify message at the time of call setup. The 
VCAT TLV Action field MUST be set to 1, which indicates that this is 
a new VCG for this call. LSPs MUST then be added to the call until 
the number of members reaches the number specified in the VCAT TLV. 


5.3.2. Setting Up a VCAT Call and LSPs without a VCG 


To provide for pre-establishment of the server-layer connections for 
a VCG, a VCAT call MAY be established without an associated VCG 
identifier. In fact, to provide for the member-sharing scenarios, a 
pool of VCAT calls with associated connections (LSPs) can be 
established, and then one or more of these calls (with accompanying 
connections) can be associated with a particular VCG (via the VCG 
ID). Note that multiple calls can be associated with a single VCG 
but that a call MUST NOT contain members used in more than one VCG. 
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To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES 
object containing the VCAT TLV MUST be included at the time of call 
setup in the Notify message. The VCAT TLV Action field MUST be set 
to 0, which indicates that this is a VCAT call without an associated 
VCG. LSPs can then be added to the call. The Number of Members 
parameter in the VCAT TLV has no meaning at this point, since it 
reflects the intended number of members in a VCG and not in a call. 


5.3.3. Associating an Existing VCAT Call with a New VCG 


A VCAT call that is not otherwise associated with a VCG may be 
associated with a VCG. To establish such an association, a Notify 
message MUST be sent with a CALL ATTRIBUTES object containing a 

VCAT TLV. The TLV's Action field MUST be set to 1, and the VCG 
Identifier field MUST be set to correspond to the VCG. The Number of 
Members field MUST equal the sum of all LSPs associated with the VCG. 
Note that the total number of VCGs supported by a node may be 
limited; hence, on reception of any message with a change of VCG ID, 
this limit should be checked. Likewise, the sender of a message with 
a change of VCG ID MUST be prepared to receive an error response. 
Again, any error in a VCG may result in the failure of the 

complete VCG. 


5.3.4. Removing the Association between a Call and VCG 


To reuse the server-layer connections in a call in another VCG, the 
current association between the call and a VCG MUST first be removed. 
To do this, a Notify message MUST be sent with a CALL ATTRIBUTES 
object containing a VCAT TLV. The Action field of the TLV MUST be 
set to 3 (Remove VCG from Call). The VCG ID field is ignored and MAY 
be set to any value. The Number of Members field is also ignored and 
MAY be set to any value. When the association between a VCG and all 
existing calls has been removed, then the VCG is considered torn 
down. 


5.3.5. VCG Bandwidth Modification 


The following cases may occur when increasing or decreasing the 
bandwidth of a VCG: 


1. LSPs are added to or, in the case of a decrease, removed from a 
VCAT call already associated with a VCG. 


2. An existing VCAT call (and corresponding LSPs) is associated with 
a VCG or, in the case of a decrease, has its association removed. 
Note that in the case of an increase, the call MUST NOT have any 
existing association with a VCG. 
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6. 


The following sequence SHOULD be used when modifying the bandwidth of 
a VCG: 


In both cases, prior to any other change, a Notify message MUST be 
sent with a CALL_ATTRIBUTES object containing a VCAT TLV for each 
of the existing VCAT calls associated with the VCG. The Action 
field of the TLV MUST be set to 2. The VCG ID field MUST be set 
to match the VCG. The Number of Members field MUST equal the sum 
of all LSPs that are anticipated to be associated with the VCG 
after the bandwidth change. The Notify message is otherwise 
formatted and processed to support call establishment as described 
in [RFC4974]. If an error is encountered while processing any of 
the Notify messages, the number of members is reverted to the 
pre-change value, and the increase is aborted. The reverted 
number of members MUST be signaled in a Notify message as 
described above. Failures encountered in processing these Notify 
messages are handled per [RFC4974]. 


Once the existing calls have successfully been notified of the new 
number of members in the VCG, the bandwidth change can be made. 
The next step is dependent on the two cases defined above. In the 
first case defined above, the bandwidth change is made by adding 
(in the case of an increase) or removing (in the case of a 
decrease) LSPs to or from the VCAT call per the procedures defined 
in [RFC4974]. In the second case, the procedure defined in 
Section 5.3.3 is followed for an increase, and the procedure 
defined in Section 5.3.4 is followed for a decrease. 


Error Conditions and Codes 


VCAT call and member LSP setup can be denied for various reasons. In 
addition to the call procedures and related error codes described in 
[RFC4974], below is a list of error conditions that can be 
encountered while using the procedures defined in this document. 
These fall under RSVP error code 39. 


These can occur when setting up a VCAT call or associating a VCG with 
a VCAT call. 


VCG signal type not supported EH 
LCAS option not supported 2 
Max number of VCGs exceeded 3 
Max number of VCG members exceeded 4 
LSP Type incompatible with VCAT call 5 
Unknown LCR (LCAS required) value 6 
Unknown or unsupported ACTION 7 
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Any failure in call or LSP establishment MUST be treated as a failure 
of the VCG as a whole and MAY trigger the calls and LSPs associated 
with the VCG being deleted. 


7. IANA Considerations 
7.1. RSVP Call Attribute TLV 


IANA has made the following assignments in the "Call Attributes TLV" 
section of the "RSVP PARAMETERS" registry available from 
http://www.iana.org. 


IANA has made assignments from the Call Attributes TLV [RFC6001] 
portions of this registry. 


This document introduces a new Call Attributes TLV: 


TLV Value Name Reference 


4 VCAT TLV [RFC6344] 
7.2. RSVP Error Codes and Error Values 


A new RSVP Error Code and new Error Values are introduced. IANA 
assigned the following from the "RSVP Parameters" registry using the 
sub-registry "Error Codes and Globally-Defined Error Value 
Sub-Codes". 


o Error Codes: 
— VCAT Call Management (39) 
o Error Values: 


Meaning Value 


VCG signal type not supported 1 
LCAS option not supported 2 
Max number of VCGs exceeded 3 
Max number of VCG members exceeded 4 
LSP Type incompatible with VCAT call 5 
Unknown LCR (LCAS required) value 6 
Unknown or unsupported ACTION 7 
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7.3.  VCAT Elementary Signal Registry 


IANA created a registry to track elementary signal types as defined 
in Section 5.2. New allocations are by "IETF Review" [RFC5226]. 


IANA maintains the following information: 


- Value 
- Type (Elementary Signal) 
- RFC 


The available range is 0 - 65535. 


The registry has been initially populated with the values shown in 
Section 5.2 of this document. Value 0 is Reserved. Other values are 
marked Unassigned. 


7.4. VCAT VCG Operation Actions 


IANA created a registry to track VCAT VCG operation actions as 
defined in Section 5.2. New allocations are by "IETF Review" 
[RFC5226]. 


IANA maintains the following information: 


- Value 
- Meaning 
- RFC 


The available range is 0 - 255. 


The registry has been initially populated with the values shown in 
Section 5.2 of this document. Other values are marked Unassigned. 


8. Security Considerations 


This document introduces a specific use of the Notify message and 
ADMIN STATUS object for GMPLS signaling as originally specified in 
[RFC3473] and as modified by [RFC4974]. It does not introduce any 
new signaling messages, nor does it change the relationship between 
LSRs that are adjacent in the control plane. The call information 
associated with diversely routed control plane LSPs, in the event of 
an interception, may indicate that these are members of the same VCAT 
group that take a different route, and may indicate to an interceptor 
that the VCG call desires increased reliability. 


See [RFC5920] for additional information on GMPLS security. 
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